This is not true. By passing a nullable primitive type as the second arg, you can use Type.Is to check for both the nullable and non-nullable version of that type. But that's just one use of the function.

Here's another way it can be used, which doesn't involve nullable types at all:
Type.Is(Int64.Type, type number)

Hi @ehrenMSFT,

Thanks for this feedback.

Here's another way it can be used, which doesn't involve nullable types at all:
Type.Is(Int64.Type, type number)

I'm puzzled. Isn't type number a nullable primitive type (where nullable primitive type = all primitive types + their nullable counterparts)?

In the language spec, operators as and is are described as only accepting "nullable primitive types as their right operand," and Value.Is's second argument is described as accepting "an arbitrary type value as its first and a nullable primitive type value as its second argument." Examples are given like Type.Is(type number, type text) and 1 is number.

Not sure about the spec. I'm just basing my comments on how things actually seem to work.

Type.IsNullable(type number) returns false. You'd have to say "type nullable number" to make it nullable.

Thanks, @ehrenMSFT!

Just opened a PR raising the question of how to best address the "nullable primitive type" terminology used in the spec.

@ehrenMSFT, just edited this to reflect the terminology that #203 has moved to. Does this look good to you now?

Where are you getting the limitation that the second type must be a primitive or nullable primitive type? I don't see any limitation like this in our code. The logic seems more involved than that.

For example, the following returns true, even though Int64.Type isn't a primitive type.

Type.Is(type number, Int64.Type)

To give other examples, this returns false:
Type.Is(type [a=number], type [a=number])

while this returns true:
let recordType = type [a=number] in Type.Is(recordType, recordType)

How does the info you added account for these examples?

Hi @ehrenMSFT!

Happy New Year!

Where are you getting the limitation that the second type must be a primitive or nullable primitive type? I don't see any limitation like this in our code. The logic seems more involved than that.

The spec mentions this limitation—https://learn.microsoft.com/en-us/powerquery-m/m-spec-types:

Compatibility between a given type and a nullable primitive type can be determined using the library function Type.Is, which accepts an arbitrary type value as its first and a nullable primitive type value as its second argument: [...] There is no support in M for determining compatibility of a given type with a custom type.

I'd assumed that the above quote from the spec is correct, and so assumed that if Type.Is seems to work when its second argument is not a primitive type or a nullable primitive type, its behavior shouldn't be relied on.

If that is inaccurate, can you advise on what is allowed as the second argument? Thanks!

Ok, thanks for clarifying I think I understand now.

Are you planning to also update m-spec-types to mention that both nullable and non-nullable primitive types are supported?

Yes! That's addressed here: https://github.com/MicrosoftDocs/query-docs/pull/203/files#diff-a63ce61286e5545a92608330795d3427bb807bc7cd0b9277a9f651b00efc5507R368